home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12019 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.6 KB
  1. Path: galaxy.ucr.edu!not-for-mail
  2. From: thp@cs.ucr.edu (Tom Payne)
  3. Newsgroups: comp.lang.c++,comp.lang.java
  4. Subject: Re: Java: What's the Big Deal?
  5. Followup-To: comp.lang.c++,comp.lang.java
  6. Date: 17 Mar 1996 20:55:26 GMT
  7. Organization: University of California, Riverside
  8. Message-ID: <4ihu7u$ogn@galaxy.ucr.edu>
  9. References: <4i40ik$9dt@news4.digex.net> <milodDo5yDE.H8B@netcom.com> <4if9jc$rkm@druid.borland.com> <milodDoF9JF.K32@netcom.com>
  10. NNTP-Posting-Host: corvette.ucr.edu
  11. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  12.  
  13. John DiCamillo (milod@netcom.com) wrote:
  14. : pete@borland.com (Pete Becker) writes:
  15. : 
  16. : >There's no reason you can't write a C++ compiler that generates a Java 
  17. : >bytestream.
  18. : 
  19. : Are you claiming that arbitrary, correct (ANSI) C++ code can
  20. : be compiled to the JVM and continue to work correctly?  Or are
  21. : you claiming that a compiler can be written that will translate
  22. : some limited subset of C++ into JVM?
  23. : 
  24. : And even if it is the former, given the limitations of the JVM,
  25. : I suspect that the performance characteristics of the resulting
  26. : program might be unrecognizable to the author.
  27.  
  28. There is no fundamental reason that g++, for instance, couldn't be
  29. targeted to JVM, just as it has been targeted to so many other
  30. architectures.  There may be some design features of JVM that make
  31. code generated for the non-Java features of C++ (e.g., pointers)
  32. particularly inefficient, but typically anything up to 10-to-1
  33. degredation is considered normal for such emulation.
  34.  
  35. : >>Other merely practical advantages (for certain kinds of apps)
  36. : >>include:
  37. : >>
  38. : >>1) Trade speed for safety (no pointer arithmetic + GC +
  39. : >>   all casts dynamically checked + array bounds + ...)
  40. : >>   This makes it a bit easier to program in than C++.
  41. : 
  42. : >Huh? Why can't you make these tradeoffs in C++? In fact, the problem is just 
  43. : >the opposite: you can't make these tradeoffs in Java because it does not let 
  44. : >you use pointers or handle your own memory management. This means you cannot 
  45. : >decide that speed is more important than safety.
  46. : 
  47. : Right, which was exactly my point.  The tradeoff has already
  48. : been made by the language in the right direction for certain
  49. : kinds of apps. Thus, there is less work for the programmer,
  50. : *assuming that you agree with the tradeoff*.
  51.  
  52. For C++ these are (mostly) implementation issues rather than language
  53. features.  Any implementation of C++ is free to make such tradeoffs,
  54. e.g., to include bounds checking, a garbage collector, etc.
  55.  
  56. : >>2) No header files => faster compilation
  57. : 
  58. : >Nonsense. Header files are simply text that gets included where you want it. If 
  59. : >you write the same code without header files it will not magically compile 
  60. : >faster.
  61. : 
  62. : It's not nonsense.  Cascaded #includes result in such a
  63. : drastic inflation of the source text that it makes a measurable
  64. : increase in compilation time.
  65.  
  66. That is an argument against using header files, or at least against
  67. using them in certain ways --- ways that are perhaps too common
  68. (but not directly required) in C++.
  69.  
  70.  
  71. In essence, Java is a P-code implementation of a (carefully chosen)
  72. subset of C++ with some librarys added.  It may be a major step
  73. forward in implementation and may point the way to a better
  74. programming style (e.g., pointerless).  
  75.  
  76. I'm very interested in the issue of just how satisfied programmers are
  77. with the expressiveness of Java, because being able to start freshmen
  78. with an interpreted implementation of a standardized, expressive,
  79. small subset of C++ (augmented with GC and bounds checking) is likely
  80. to make life easier both for them and for me.  I doubt, however, that
  81. I would select Java for a data structures class.
  82.  
  83. Tom Payne (thp@cs.ucr.edu)
  84.